fix: multi-account sync disappearing calendar and stuck import - #2772

Email/password signup followed by Settings → Add account hid the original Compass calendar and left "Adding your calendar…" stuck. This PR fixes both the UI attribution and the import-state push/pull path, plus a sign-in fork guard.

Summary

1. Local calendar vanished. CalendarList hid provider === "local" once any Google connection existed (LCV3). That premise is false for email/pw signup → add Google. Day view also dropped local columns while Week kept them. Empty account groups were filtered out, so a just-connected account had no section to hang "Adding your calendar…" on.

2. Import never converged in the UI. importing → healthy was computed lazily only on sync GET /connections. Bootstrap completion did not push a connection invalidation. SSE handlers refreshed metadata without force, focus reconciliation was disabled during IMPORTING, and a missing events resource stayed importing forever. Reconnect clobbered lastHealthyAt, so an established account looked like a first import.

3. Add account could bind to reconnect. useConnectGoogle pinned connectionId whenever any account was RECONNECT_REQUIRED, so Settings "Add account" became a reconnect and failed with "Reconnect account does not match the named connection".

4. Sign-in fork. An authenticated user hitting the Google sign-in path (?auth= → POST /api/signinup) with an unrecognized Google account silently created a new Compass user.

Sync — deterministic import-state convergence

• Call refreshConnectionState after bootstrapCatchup and subscriptionMaintain unsupported set bootstrapState to ready (try/catch; never fail the job).
• Missing events resource uses the calendar row's updatedAt as the stall basis → delayed after BOOTSTRAP_STALLED_AFTER_MS.
• Refresh CTA enqueues coalesced calendarListSync per connection so discovery heals resource-less calendars.
• lastSyncedAt / lastHealthyAt move to $setOnInsert so reconnect does not clobber them.

Web — metadata refresh discipline

• SSE handlers, stream open/reopen, and focus always refreshUserMetadata({ force: true }).
• Provider refresh stays gated to HEALTHY/ATTENTION; metadata is not.
• 20s poll while any single connection is connecting / importing / catchingUp.
• Concurrent force calls still chain onto one trailing fetch; epoch counter drops stale writes.

Web — sidebar + Day view

• Local calendar is its own Compass-email section (no collapse/status/CTA) when Google accounts exist. LCV1/LCV2 still exclude local as a create target (getWritableCalendars / getDefaultTargetCalendar).
• Empty seeded account groups are kept so importing accounts render a header.
• Day columns are active+visible calendars, matching Week. Click-to-create on a Day column uses the same writable set, so the restored local column is visible and toggleable but not a create target after Google is connected.

Web — Add account

• useConnectGoogle({ newAccount: true }) always begins with {}. Settings Accounts section uses it.

Auth fork guard

• ?auth= is ignored (and stripped) while a session exists.
• handleGoogleAuth refuses SIGNUP when input.session is present: "You're already signed in — use Settings → Add account to connect this Google account."

Architecture invariants: docs/architecture/multi-account-sync.md.

Simplicity

Kept zustand for user metadata (refresh discipline, not a store migration). refreshConnectionState remains the only derived-state writer. No second SSE push channel. The Day create gate reuses getWritableCalendars instead of a new local-exclusion rule.

Automated validation

• Package tests cover the reported bugs (sidebar local section + toggle, empty importing account header, Day local column visibility, metadata force/poll, reconnect timestamps, bootstrap invalidation, Add-account newAccount, ?auth= while signed in, SIGNUP-under-session).
• Full Google OAuth add-account path was not exercised in this environment (no SuperTokens/Google secrets). Login flows were not run against an incomplete backend, per AGENTS.md.

Independent review

Confirmed finding fixed: Day click-to-create on the restored local column after Google connect (LCV1/LCV2). Residual: dragging a Google event onto the local Day column can still retarget it; duplicate sidebar headings if Compass email equals a connected Google email; SIGNUP guard runs after SuperTokens signInUpPOST.

Test plan

• bun test:sync — 900 pass
• bun test:web — 2195 pass, then DayCalendarGrid 31 pass after the create-target fix
• bun test:backend — 307 pass, 1 skip
• bun type-check
• bun lint (pre-existing warnings only)
• GitHub Test + CodeQL on the previous head were green; this head re-runs them